1. Field of the Invention
The invention relates in general to circuit emulators and in particular to a debugger-controlled circuit emulator controlled by a debugger that can interrupt an emulation in response to events occurring in emulator signals detected by a logic analyzer.
2. Description of Related Art
Integrated circuit (IC) designers frequently employ circuit simulators and emulators to verify that ICs fabricated in accordance with their designs will behave as expected.
A computer-based circuit simulator calculates how signals produced by the IC would respond to particular input signals patterns based on mathematical models of transistors and other devices included in the IC and produces a “dump file” containing waveform data sequences presenting the behavior of its input, output and internal signals. When a simulator bases its calculations on accurate device modules, its output data can provide highly accurate and detailed information about the behavior of every signal of the simulated IC. Although a simulator can be used to verify both the IC logic and timing, circuit simulation can be time-consuming; a simulator may need several hours or more to simulate a few seconds of IC behavior.
A circuit emulator includes a set of hardware devices such as programmable gate arrays, memories and other emulation resources that are interconnected and programmed to emulate the behavior of an IC described by a netlist or other form of circuit description. Since an emulator transmits and receives real signals, it is sometimes used as an “in-circuit emulator”, acting as a substitute for the IC being emulated in the context in which the IC is to be used. For example, if an IC is to be installed in a socket of a circuit board, an emulator emulating the behavior of that IC connected to that socket can communicate with other circuits on the circuit board via signals in the same way the IC would. While an emulator usually cannot operate at clock frequencies as high as the IC it emulates, emulations are usually faster than simulations when carried out at comparable levels of an IC design.
A “co-simulator” includes both an emulator and a simulator for concurrently emulating and simulating separate portions of an IC and for transmitting and receiving data to and from one another representing states of the input/output signals of those separate IC portions. A co-simulator is useful for modeling behavior of a large IC including some portions of proven design whose behavior need not be verified in detailed and other portions that are newly designed and require detailed verification. For example when an IC design to be verified includes an embedded computer of proven design along with some custom designed circuits, the simulator can simulate the embedded computer at a relatively high level while the emulator can emulate the custom circuits.
An emulator includes a data acquisition system for monitoring various emulator signals during emulation and storing data representing behavior of emulator signals during an emulation, including input, output and internal signals of emulator resources. A circuit designer can use a computer-based “debugger” to produce waveform and other displays based on that data that the designer can analyze to determine whether the emulated IC behaved as expected and to help the designer to track down design errors that lead to unexpected signal behavior. Since the high-speed memory that the data acquisition system of an emulator uses to store the data during emulation has a limited storage capacity, a user can program the emulator to monitor only a limited set of emulator signals of interest during the emulation and to store data representing only that limited set of monitored signals. One drawback to this is that if upon using a debugger to review the data collected during an emulation, a user decides he or she would like to review the behavior of any unmonitored signals, it is necessary to reprogram the emulator to monitor those signals and then repeat the emulation in order to collect data representing those signals. Having to repeat an emulation several times in order to collect enough data to track down error sources can greatly increase debugging time.
One way to increase the amount of data an emulator can collect during an emulation without increasing the amount of data acquisition memory needed to store the data is halt the emulation when the memory is full, transfer the data stored in its memory to a hard disk, and then resume the emulation. The drawback to this approach is that frequently interrupting the emulation to flush the data acquisition memory can substantially increase the time required to carry out emulation.
The data currently stored in the internal data storage devices of the emulator such as flip-flops, registers, latches, random accesses memories and the like at any moment during an emulation constitute the current state of an emulated IC at that moment. Some emulators periodically store state data representing “snapshots” of the current emulated IC state during emulation so that if the designer wants to restart an emulation at a some point at which the emulator collected state data, he or she can command the emulator to reload the state data into the emulators storage devices, thereby restoring the emulation to its state at that point. The designer can then restart the emulation at that point. This capability helps to reduce debugging time by making it unnecessary to repeat an entire emulation in order to obtain data representing signal behavior during only a portion of the emulation. Although the snapshot system allows the designer to restart an emulation at a selected point, it does require an emulator to periodically halt an emulation so that it can transfer state data to a hard disk, since an emulator normally does not have the high speed memory resources needed to store all of the state data collected during emulation.
Although a debugger processes the data representing emulator signals, an emulator and a debugger are separate devices. A designer controls an emulator mainly by programming it, but controls a debugger interactively through its display. When a designer using a debugger discovers an error occurred in one the signals it represents and wants to makes some changes to the emulation, for example so that it collects data representing different emulator signals, the designer must reprogram the emulator. The process of iteratively using a debugger to investigate emulation results and then reprogramming the debugger based on that investigation can be time-consuming. What is needed is a system that more closely links a debugger and an emulator so that a user can use a debugger not only to review the results of an emulation but to interactively control and modify the emulation process.